Enterprises and Service Providers are now typically migrating their services and equipment to Voice over Internet Protocol (“VoIP”). Present VoIP Communications Systems offer customers both a rich set of advanced features and the ability to quickly add new functionalities as the requirements on the market change and grow.
IP Private Branch Exchanges (“PBXs”) in particular have gained strong traction in the marketplace and their deployments outpace the traditional time division multiplexing (“TDM”) PBX deployments. Also, Service Providers are now quickly developing their network nodes using VoIP to increase productivity and deploy new services.
The Telephony Network Manufacturers (“TEMs”), Network Equipment Manufacturers (“NEMs”), and the Service Providers (“SPs”) have largely reached a consensus that the Session Initiation Protocol (“SIP”) is the most appropriate protocol choice to use in the VoIP world. Conversely, selecting the SIP protocol alone to implement VoIP features and services is not enough. As long as a large family of Internet Engineer Task Force Requests for Comments (“IETF”, “RFCs”) exists, the SIP implementations offered by many TEMs, NEMs and SPs rarely implies support of all related RFCs or even the entire functionality stated into a specific RFC. Moreover, there are often multiple ways of achieving the same technical result in SIP, a fact that further complicates interoperability with other third-party SIP devices and services.
The legacy facsimile technology is still in use even the medium and large enterprises are finding that scanning documents and sending them as PDFs files can successfully replace the old fax machines. The regulatory requirements continue to make the facsimile documents imperative; therefore, many businesses continue to send and receive hard documents using legacy technology. Nowadays, companies are trying to minimize the telephony hardware costs by relying on SIP trunks to connect to the service provider's networks that terminate the calls onto the PSTN (Public Switched Telephone Network). This natural shift to IP services requires that the Service Provider IP backbone must be T.38-compatible in order to have interoperable fax-relay endpoints in every call.
The most important challenge TEMs, NEMs and SPs are confronting is the interoperability assessment between their IP products and the third-party products they have to interoperate with. As shown in FIG. 1, usually this is accomplished by using actual IP telecom devices and services, provided by the third-party manufacturers, directly connected to their products in a lab. This approach becomes very expensive as long as multiple third-party devices and services are required for a comprehensive interoperability assessment. Such testing is labor intensive, expensive, requires complex test beds, and often results in an incomplete assessment.
As a practical matter, many testing facilities do not have the resources to purchase all of the third-party IP network equipment designed to interact with target IP telecom products. This can lead to instances where the IP telecom product cannot be adequately assessed for interoperability before being released to market. Accordingly, it is desirable to provide a method for emulating third-party IP telecom devices and services that a IP telecom product is intended to interact with so that the product can be tested without having to purchase an expensive and numerous set of third-party IP devices and services, for example SIP or T.38 Fax-relay Enabled Devices and services.
Another problem of the interoperability assessment is that every feature provided by the IP telecom product is tested for interoperability one-by-one, often manually, thus causing the entire task to be very labor-intensive. Therefore, due to the amount of time required and the costs involved, it is critical to automate the interoperability assessment in the lab.
Another problem for TEMs, NEMs and SPs is that the IP telecom devices and services are upgraded periodically to add new features or to correct existing bugs. Whenever these types of changes are made to complex software systems, for example a IP target system telecom product, a tremendous risk exists that these changes or additions to the IP target system could corrupt its existing functionality, and inherently the interoperability with third-party IP telecom devices and services. This problem requires a comprehensive regressive interoperability assessment of the IP target system with all third-party IP devices and services it is designed to inter-work with. Again, due to the amount of time required, it is critical to automate the regressive interoperability assessment as much as possible.
The complete and precise emulation of actual devices and services is not a simple task for VoIP and FoIP protocols such as SIP and T.38. As mentioned above, TEMs, NEMs and SPs rarely offer support of all related standard recommendations in their SIP and T.38 fax-relay implementations. Moreover, they tend to add proprietary extensions, for example, as new features that affect the SIP protocol messages syntax and content, even the message flow. Consequently, an effective system and method for emulating the actual device and service behaviors necessarily includes all these “deviations” alongside the IETF and ITU-T standard specifications.
The communications devices and services exhibit different response delays for different inputs implied by both the traffic load and the intrinsic processing algorithms efficiency. Again, a successful method and system for emulating an actual device and service must replicate, for example, the T.30/T.38 signal timing of the T.38 Fax-relay device that is being emulated. For example, multiple time measurements are considered and processed according to a statistical model due to stochastic characteristic of the IP environment.
Another important challenge for proper emulation of the actual IP telecom device and service behavior is the automated analysis of real-life telecom traffic generated by the target system, for example, to extract the deviations for SIP traffic against the IETF standard specifications or T.38 Fax-relay traffic against the related ITU-T recommendations. For example, the full set of features of an actual SIP device and service must be exercised and the related traffic stored for complete analysis. Once an automated analysis is done and the set of deviations identified, they can be stored as a device and service behavioral profile along with the related message stamps for later use in the emulation stage.
The current invention comprises of an efficient method of interoperability assessment of IP Telecom Communications Platforms based on automated Behavioral Profiling and Emulation of real-life SIP enabled devices, for example, SIP phones or SIP Internet Aware Fax Terminals.
For effective interoperability assessment the presently disclosed system and method consists of two stages: (1) Behavioral Profiling using a Multi-Step/Multi-Technology Iterative Profiling process and (2) Device Emulation process.
An illustrative embodiment of the present disclosure includes a system for and method of efficient interoperability assessment based on automated Behavioral Profiling and Device Emulation of actual SIP or T.38 Fax-relay Enabled Devices, including device traffic analysis and generation of the associated Behavioral Profile, device message syntax/signal parameters and content analysis to generate the associated Behavioral Profile, device message/signal flow sequence analysis to generate the associated Behavioral Profile, device signal timing (timestamp) analysis to generate the associated Behavioral Profile. The system and method including a Multi-Step/Multi-Technology Iterative Profiling Stage of a actual SIP or T.38 Fax-relay Enabled Device, Device Emulation Stage of a actual device, generation of different actual telephony scenarios based on Behavioral Profiles, Device Emulation of multiple different actual SIP or T.38 Fax-relay Enabled Devices at the same time, and the ability to store and retrieve Behavioral Profiles into XML files or other database forms.